Information drives business. For businesses that increasingly depend on data and information for their day-to-day operations, unplanned downtime due to data loss or data corruption can hurt their reputations and bottom lines. Businesses are becoming increasingly aware of the costs imposed by data corruption and loss and are taking measures to plan for and recover from such events. Often these measures include making backup copies of primary, or production, data, which is ‘live’ data used for operation of the business. Backup copies of primary data are made on different physical storage devices, and often at remote locations, to ensure that a version of the primary data is consistently and continuously available.
One way to achieve consistency and avoid data loss is to ensure that every update made to the primary data is also made to the backup copy, preferably in real time. Often such “duplicate” updates are made on one or more “mirror” copies of the primary data by the same application program that manages the primary data. Mirrored copies of the data are typically maintained on devices attached to or directly accessible by the primary node, and thus are subject to failure of the primary node or to corruption of data that are accessible via the primary node. To ensure against these types of failures, data are also often replicated to a secondary location whenever an update is made to the primary data.
Typically, a secondary node is remote from the physical location of the primary node and can be accessed via a network, although it is not a requirement that the secondary node be physically remote. Primary and secondary nodes may be implemented as computer systems that communicate using a communication link, typically over a network connecting the primary and secondary nodes to other nodes. Data are replicated from the primary node, where an application program is running, to one or more secondary nodes. In many replication environments, each write operation by the application to the primary data results in one write operation to a log and another write operation that is replicated to the secondary storage area.
If the primary and secondary data become unsynchronized (after a primary node failure, for example), the primary and secondary data are resynchronized to establish a consistent starting point before replication can be restarted. Copying the entire set of primary data to each backup copy is one method to ensure that the data are consistent between the primary and secondary nodes. However, copying the entire set of primary data to each backup copy at secondary nodes uses network bandwidth unnecessarily when only a small subset of the primary data has changed since the most recent backup operation. Furthermore, copying the entire set of primary data across a network requires a significant amount of time, especially when large amounts of data, such as terabytes of data, are involved.
These factors weigh in favor of copying only data that have changed since the most recent backup operation to the replication storage area. One technique for copying only changed data is to establish an initial consistent copy of the primary data, and then send only changes to the primary data to the replication data storage. Such implementations typically maintain a log of changes and replicate each operation in the log in the same order in which the change was made to the primary data. Thus, the replication data is the same as the primary data, allowing for a time lag for data to be replicated from the primary node to the secondary node. If the primary and secondary data become unsynchronized due to an interruption in the replication process, the differences are captured as the changes in the log that have not yet been replicated to replication data storage. To synchronize primary and secondary data, only the unreplicated changes remaining in the log must be copied to the secondary data storage. This technique increases the efficiency of the resynchronization process.
But even using a change log does not solve all inefficiencies of maintaining replication data. If the log becomes full as a result of communication or node failure between the primary and secondary nodes, data for individual write operations can be lost. Typically, in such a case, the log is read to identify regions of primary data that have been changed but not replicated, and the entire region is copied from primary data storage to replication data storage. However, with the increasing size in enterprise data sets and lowered costs of data storage, logs on the order of several terabytes may exist. The time required to read the log itself to identify unsynchronized regions becomes a significant consideration. Furthermore, once primary and secondary data have become unsynchronized, an entire region's data are copied over the replication link. Only a small portion of the region's data may have changed, thereby resulting in wasted effort in copying data that have not changed.
An alternative to copying full regions is to read the log and send each write operation that has not yet been replicated. Such a synchronization method is sometimes referred to as “replaying the log.” However, if certain areas of storage have been updated more frequently than other areas, other inefficiencies may occur. For example, if the application has “hot spots” on a disk that have been repeatedly updated, it is preferable to copy only the most recent update of the hot spot to the replication storage area. Resending each write operation in the log wastes effort by copying data that are replaced numerous times in subsequent write operations.
What is needed is the ability to maintain consistent, up-to-date secondary copies of primary data that enable quick resumption of operations upon a discovery that primary and secondary data have become unsynchronized. Preferably the solution would identify unsynchronized regions quickly and ensure that data are copied efficiently, with minimal or no duplication of effort or data.